IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end subscribers will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7). IMS provides key features to enrich the end-subscriber person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between subscriber terminals (or subscriber terminals and application servers). The Session Description Protocol (SDP), carried by SIP signaling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a subscriber-to-subscriber protocol, IMS allows operators and service providers to control subscriber access to services and to charge subscribers accordingly.
By way of example, FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network (IMS can of course operate over other access networks). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the subscriber that the subscriber is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
A subscriber registers with the IMS using the specified SIP REGISTER method. This is a mechanism for attaching to the IMS and announcing to the IMS the address at which a SIP subscriber identity can be reached. In 3GPP, when a SIP terminal performs a registration, the IMS authenticates the subscriber, and allocates a S-CSCF to that subscriber from the set of available S-CSCFs. Whilst the criteria for allocating S-CSCFs is not specified by 3GPP, these may include load sharing and service requirements. It is noted that the allocation of an S-CSCF is key to controlling (and charging for) subscriber access to IMS-based services. Operators may provide a mechanism for preventing direct subscriber-to-subscriber SIP sessions which would otherwise bypass the S-CSCF.
During the registration process, it is the responsibility of the I-CSCF to select an S-CSCF if a S-CSCF is not already selected. The I-CSCF receives the required S-CSCF capabilities from the home network's Home Subscriber Server (HSS), and selects an appropriate S-CSCF based on the received capabilities. [It is noted that S-CSCF allocation is also carried out for a subscriber by the I-CSCF in the case where the subscriber is called by another party, and the subscriber is not currently allocated an S-CSCF.] When a registered subscriber subsequently sends a session request to the IMS, the P-CSCF is able to forward the request to the selected S-CSCF based on information received from the S-CSCF during the registration process.
Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality. Application Servers provide services to end-subscribers in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which Applications Servers should be “linked in” during a SIP Session establishment (or indeed for the purpose of any SIP method, session or non-session related). The IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a subscriber's Subscriber Profile.
FIG. 2 illustrates the IMS Service Control (ISC) interface between an AS and an S-CSCF, as well as other interfaces within the IMS. Although the AS in FIG. 2 is shown as having only a single interface to an S-CSCF, it will be appreciated that in practice the ISC interface will extend across a communication network to which many (or all) of the CSCF servers of a given operator's network are connected, allowing an AS to communicate with all of these CSCFs. [Other entities illustrated in FIG. 2 will be well known to those of skill in the art.]
A further interface (Ut) exists between the AS and the subscriber terminal (TS23.002) although this is not shown in the Figure. The Ut interface enables the subscriber to manage information related to his or her services, e.g. creation and assignment of Public Service Identities, management of authorisation policies that are used for example by “presence” services, conference policy management, etc.
In the IMS as defined in 3GPP, whilst subscribers are statically allocated to an HSS, it is the ASs that provide specific value in the case of services provided by the network. A reading of the 3GPP specification in Releases 5 and 6 suggests that subscribers are allocated to particular SIP ASs in a fixed manner. The basic concept is that a subscriber is provisioned to be supported by a specific SIP AS application server for a given service or services. In order to enable the allocated S-CSCF to reach the allocated AS over the ISC interface, the filter criteria (contained within the IFC sent to the S-CSCF from the HSS) for that subscriber for that service contains either a fully qualified domain name (FQDN) or IP address as the destination address (encoded as a SIP-URI). This implies, for example, that when the S-CSCF identifies that a particular INVITE should be routed to an AS, the S-CSCF is provided with the address of the specific AS over via the Cx interface. In order to identify the correct AS for other interfaces, e.g. such as the Ut interface between the subscriber terminals and the SIP-ASs, routing proxies are provisioned with the address of the AS for the particular subscriber. Where subscribers are allocated to specific ASs, then either the terminal is configured with the address of the AS for that interface and service, or the terminal sends the request to an entity that knows how to retrieve the address of the AS for that subscriber. A “front end” could do this and, in such a case, the routing functionality would be configured into the front end.